|
|
|
|
|
|
|
Encapsulation for Subsystems |
|
|
|
|
|
|
|
|
Rules for encapsulation that apply to classes also apply to subsystems in the large. Subsystem encapsulation is protected by one or more boundary classes, whose responsibility it is collectively to fulfill the contract of the subsystem to its clients. |
|
|
|
|
|
|
|
|
On Day 6, you simplified the ActiveX component so that the BasicPersonalChecking class performed the role of the boundary and entity class. (No control class was needed because the gap between the subsystem boundary and the entity objects was nonexistent.) As a boundary class, the BasicPersonalChecking class interacted with its client (FormController). As an entity class, it also supplied a service based upon the client's request for operation. For my simple example, this was acceptable, but for more complex projects, it usually is necessary to keep entity classes pure of subsystem implementation details that are better handled by boundary and control classes. |
|
|
|
|
|
|
|
|
Identifying and Using Design Patterns |
|
|
|
|
|
|
|
|
One of the most useful attributes of well-defined subsystems and components is that they can be reused. Subsystems can themselves implement one or more design patterns, with the usual case being one or two patterns. To identify and implement design patterns for subsystems and components, you use the same rules as for applications. |
|
|
|
|
|
|
|
|
Defining the Design Pattern |
|
|
|
|
|
|
|
|
Defining a design pattern includes determining the problem to be solved by the pattern and the subsystem service it will help fulfill. (Recall the factory example of Day 3.) A bank teller application would have a partition dedicated to providing access to specific bank products, so the AccountCreator class and each of the bank product classes constitute an application subsystem. You could have created an ActiveX component from the AccountCreator Factory pattern implemented in this project. |
|
|
|
|
|
|
|
|
Naming the Design Pattern |
|
|
|
|
|
|
|
|
The rules for naming a design pattern are the same as for an application. Of course, the name should be relevant to the subsystem or component in which it is to be implemented. A design pattern seeks to solve a design problem that the subsystem needs solved. Simple, clear design pattern names help to increase the vocabulary of the developers on your project and in your enterprise; they also help you avoid duplication of code across several subsystems and components you own. |
|
|
|
|
|
|
|
|
Reuse of subsystems starts with your not duplicating a design solution and often leads to encapsulation of a subsystem into a component. Help others use your pattern by |
|
|
|
|
|